DID (Encryption, SIgnature)
署名と暗号化の機能を持ったDIDを作りたいYudai.icon
つまり1つの秘密鍵で署名と暗号化両方できる
今だと疑似的に署名認証によって空間へのアクセスが出来る状態
鍵が2つある(EOAのsk, Root Nodeのsk)
暗号化のアルゴリズムを作るに近いのか、使用するアルゴリズムを変えるに近いのかな？
=> ルートノードの秘密鍵とDIDの署名の秘密鍵が＝で結ばれるって事やね
懸念点は圧倒的に秘密鍵の流出により、全ての権限を失う事
ただこの部分はレイヤーが違うと言えば違うし、他のプロジェクトで実際に開発や検証が行われているから僕たちが行う必要があるかと言ったら関係ないと思う
これ新しいDID methodを作るに近いのか、はたまた新しいアルゴリズムを作るに近いのか分からないけど、これからのスコープとして必要になってくる
僕の感覚だとMonas用のDID methodを作る形にした場合ユースケースが限られることが懸念しているYudai.icon
ってかさ、ありそうよね(DWNはそんなような発表はしてたけど見つけられていないYudai.icon) 見つけられなかったからSlackで聞いたYudai.icon
Hi @Yudai Ishikawa! When you say DID encrypt, I assume you mean store encrypted data in someone's DWN that only they can read, or store encrypted data in your DWN and grant access to someone to be able to decrypt it based on their DID.
Our spec documentation is very out of date, and we are working towards fixing that, however you can look at examples in the reference implementation of how it's used:
Here are some of the technical proposals that share a bit more details of what is done for encryption:
It is also currently in the process of being brought into the web5 sdk which is a more user-friendly way of interacting with DWNs. It's part of a broader effort to bring a signing agent and delegation capabilities to web5 , allowing for such things as external signers and HSMs.
これだと署名認証ができればアクセスできる状態とも言えていて鍵が2つある状態を解決は出来ていないYudai.icon
って返信してみたYudai.icon
Hi Yudai!
This describes our scheme wrt your question if I'm understanding it correctly.
We use an ECC Public Key Pair to derive an AES key for each data path.
問題提起: DWebノードは、ユーザーと許可された外部エンティティが暗号化されたレコードを作成し、読み取るためのメカニズムを必要としています。
提案:
各DID（分散型識別子）には、そのDIDドキュメント内にECC（楕円曲線暗号）の公開暗号化鍵が含まれること。
この鍵は、データ暗号化のためのHD（階層型決定論的）派生マスターキーとして使用される。
レコードの任意の論理的階層構造におけるパスを表す文字列セグメントを使用して鍵を派生する。
複数の鍵派生スキームを定義して、レコードの論理的かつ階層的な構造をKDF（キー派生関数）に適用する。
結果: 外部参加者は、受信者の公開鍵を使用して特定のレコードの公開鍵を派生し、そのデータをECIES暗号化する方法を正確に知ることができる。
鍵派生スキーム: プロトコル、プロトコルパス、スキーマ、データフォーマットなどに基づいて、レコードの暗号化解除を可能にする様々な鍵派生スキームが識別されています。
データ暗号化スキーム: ECIES（楕円曲線統合暗号スキーム）を使用し、AES対称鍵を暗号化するために非対称ECC鍵を使用することが推奨されます。 検討事項: サポートする鍵セットを拡張する必要がありますが、実用上の理由から、DWN暗号化機能の初期段階で実装するべき鍵/アルゴリズムの組み合わせとKDFスキームを選択することが望ましいです。
多分僕の理解が正しければ現状Monas対称鍵でCryptreeを実装していて、ルートキーは非対称鍵、子孫キーは非対称鍵ってことが出来るって事かも？ いや、あり得んか、公開鍵ペアから対称鍵を作るって意味が分からんYudai.icon
chatGPT.iconと話していて僕自身の前提がいろいろと間違っているからできないと感じたのを理解してきた
ECCベースで鍵の生成を行うから署名と暗号化どちらでも可能ではある 一方で鍵の生成アルゴリズムが署名、暗号化それぞれに特化しているからこそ他で使用することは推奨されていない
つまり実装することは出来そうではあるがどのような鍵生成アルゴリズムを使用するかによりそう